When a client requests a piece of content such as digital video, audio, or some other content from a server, the client typically provides a global address to the content in the form of a Uniform Resource Locator (URL). The server then accesses the addressed content and sends or “streams” it to the client in the form of a continuous digital data stream.
There are various file data formats for streaming digital media content and composite media streams. “Advanced Streaming Format” (ASF) is an example of such a data file format. ASF (sometimes referred to as WINDOWS Container Media Format) specifies a way in which multimedia data content is stored, streamed, and presented by a variety of tools, servers, and clients of a number of different multimedia vendors. ASF provides a storage and transmission data file format that encapsulates multimedia data types (e.g., images, audio, and video) as well as embedded text (e.g., a URL) and also allows for synchronizing these objects within a digital data stream. (Further details about ASF are available from Microsoft Corporation of Redmond, WA.).
Regardless of which of a number of different streaming file data formats is used, an individual data stream includes a sequence of digital data sets or units. The units represent an image, sound, or some other stimuli that is perceived by a human to be continuously varying. The client renders the units individually, in sequence, to reproduce the original stimuli. For example, an audio data stream comprises a sequence of sample values that are converted to a pitch and volume to produce continuously varying sound. A video data stream comprises a sequence of digitally specified graphics frames that are rendered in sequence to produce a moving picture.
In the simplest case, a client requests a single streaming media content file, to reproduce, or “play” a single piece of content such as a song or a video. Alternatively, the client may request a playlist, or “playlist file” that includes a number of different references to individual streaming media content files. Each playlist file includes information such as information to reference specific pieces of content, an order in which to play the referenced content, and other information (e.g., whether to play certain pieces of referenced content more than one time). In other words, a playlist file not only references media content, but also describe how pieces of media content are combined.
Playlists do not normally contain the actual media data, but rather particular references (i.e., a URL) to stored media data. As a result, a playlist file is typically small in size, generally only contains text, and is typically easy and computationally inexpensive to modify. (A reference to a single piece of media content may appear in any number of different playlist files).
A playlist is typically created in predetermined format. The Synchronized Multimedia Integration Language (version. 2.0), referred to as “SMIL” is an example of such a predetermined format. SMIL is an extension of the World Wide Web Consortium (W3C) standard Extensible Markup Language (XML). SMIL provides syntax and structure to define both high-level instructions and data corresponding to the content referenced by a playlist. (The specification for SMIL is well understood in the computing industry).
A playlist can be implemented on a client computer or on a server computer. When a client implements a playlist, the playlist is typically downloaded from a server. The client interprets the downloaded playlist file to present a series of requests to the server, for every piece of content represented in the playlist. A server, upon receipt of a media content request from a client, is generally not aware that the client is requesting media content that is referenced in a client implemented, or “client-side” playlist file. This is because use of a client-side playlist is indistinguishable from a client requesting a server to play one or more respective pieces of media content one-after-the-other.
A server implemented playlist, or “server-side” playlist is maintained by a server and is not downloaded to a client. To access media content represented in a server-side playlist, a client typically selects a URL that identifies both a server and a particular playlist file. Responsive to receiving a request from the selection of such a URL, the identified server accesses the requested playlist and streams, or “plays” the media content referenced by the playlist to the requesting client, one piece of media content at a time.
Regardless of whether a playlist is implemented on a server or on a client, a playlist can play a substantially important role in building a business based on advertising, source branding, service branding, and/or other revenue basis. For example, a playlist file can allow a content provider (e.g., an Internet radio station) to embed, or combine an advertisement, a brand name, and/or other content such as multimedia content previews, radio-station identifiers and/or the like with scheduled media content. Every time that a content provider chooses to modify an advertisement, branding information, and/the like, that is embodied in a playlist, the content provider must typically modify the playlist to excise the old content to incorporate the new content. Or, the content provider can remove the old playlist and create a completely new playlist to reflect the change(s). Such playlist modifications and may be brought about for any number of reasons such as changes in business methods, regulatory constraints, audience demographics, and/or the like. It can be appreciated that a content provider such as a radio or television station may have any number of playlists (e.g., one playlist, one-hundred playlists, one thousand playlists, or more) that need to be modified, and or created to reflect such changes. Thus such playlist media content changes typically require a substantial amount of administrative overhead.